Kind of off-topic: I was forced to use the more verbose Vec::new() syntax in all the tests because, when I used vec![], this check would prevent the lint from firing. That doesn't sound quite right to me?

But also, two more high level questions here:

1. Should this also recurse into reduce_expression() with the start and end expressions of the range, to reduce it even further? I see this also isn't consistently done for some other kinds of expressions, like for array literals and struct expressions, so I'd also be fine with leaving it, but I'm not sure why it's done this way.

2. Why do we return None/not reduce ranges at all if their type isn't certain, instead of only reducing the applicability like we do for structs in general? It still seems worth linting range expression statements that exist solely to make the inner expressions type-check.

1. I think reducing too much in one go can end up creating some pretty confusing suggestions.. Although maybe they could make sense for the target audience of this lint (who I'm not really sure who is, except for people that have made a typo in a quick reproducer -- in which case the complete reduction might be actively counter-productive for understanding what the lint wants from them)
2. I could totally make that change, yes. I guess it was just me too closely copying the structure of the regular Struct arm -- there, the suggestion is deleted when the type has an explicit Drop impl

I've implemented 2. for now